Generally, the present application relates to data processing. More specifically, the application is related to techniques for multi-factor authentication.
Modern businesses rely on a variety of applications and systems that control and generate information that is critical to business operations. Different applications often provide different services and information, and different users may require access to different levels of information within each system or application. The level of access that users are granted may depend on the role of the user. For example, a manager may need access to certain information about employees that report to him, but it may be improper for that manager to access the same information about those whom he reports to.
Earlier, less sophisticated applications incorporated access management business logic directly into the application code. That is to say, each application would require users to have a separate account, separate policy logic, and separate permissions, for example. Furthermore, when a user is authenticated by one of these applications, this authentication remains unknown to other applications in the enterprise because the fact that authentication with the first application has taken place is not shared. Thus, there is no concept of trust between applications using different systems for authentication and access control. Engineers quickly realized that having an access management system for each application in an enterprise was much like having a gas station for each car, and determined that authentication and access control would be more efficiently implemented and managed as a shared resource. These shared resources became known as an access management systems.
Access management systems often use policies and other business logic to make a determination regarding whether a particular access request should be granted to a particular resource. Upon making a determination that access should be granted, a token is provided to the requestor. This token is like a key that can be used to open a door that guards restricted data. For example, a user may attempt to access a human resources database to gather information about certain employees such as salary information. The user's web browser makes a request to the application, which requires authentication. If the web browser does not have a token, the user is asked to log in to the access management system. When the user is authenticated, the user's browser receives a cookie that represents a token that may be used to access the human resources application.
In enterprise and cloud environments, users (e.g., employees) typically may have access to one or more different systems and applications. Each of these systems and applications may utilize different access control policies and require different credentials (e.g., user names and passwords). Single sign-on (SSO) can provide a user with access to multiple systems and applications after an initial login. For example, when the user logs-in to their work computer, the user can then also have access to one or more other resources, such as systems and applications. An access management system may challenge a user to verify his/her identity to determine access to a resource. The user may be challenged for information based on a combination of “what you have,” “what you know,” and “who you are.”
Access management systems can prompt a user with a graphical user interface on a client device to challenge the user for information to verify the user's credentials. Sometimes, information requested of a user may include sensitive, confidential information, which if comprised, may threaten the identity and personal information (e.g., financial information or account information) of the individual. As a result, users may be hesitant to provide sensitive information to a system, such as a server, to gain access to resources, without being sure that the system requesting the information does actually control access to those resources.
With on-going technology-based advances in identity theft using techniques such as spoofing and phishing, users are even more reluctant to provide their credentials without being sure that the recipient is an access management system. Access management systems are also unsure as to the authenticity of the source of credentials. In some instances, a client system may receive a one-time code (e.g., password) to enable the user operating the client system to access a resource via the access management system. The client system, if compromised or stolen, may enable a user operating the client system to obtain unauthorized access to a resource using the one-time code. Though passwords have been an accepted norm for authenticating users and providing access, they are fraught with problems—people forget their passwords or make it easy enough to be guessed. Using layered security and multiple factors of authentication is gaining ground as a more secure method authentication to prevent fraud.
With a shift towards cloud-based environments, access management encounters further challenges that introduce difficulty in providing trust for identity management. Techniques such as multi-factor authentication (MFA) and knowledge-based authentication (KBA) may be employed to ensure greater security for access management. The growth of social networking has introduced vulnerabilities into MFA and KBA. MFA may rely on a trusted device to provide stronger authentication, but may not prevent access when the device is lost or stolen. KBA may rely on user's private information such that KBA may be compromised. Personal information may be accessible through social networking such that secure forms of authentication such as MFA and KBA may be compromised. Some access management systems may employ different techniques for access management; however, such access management systems may be susceptible to security vulnerabilities through one or more of credential guessing, phishing, eavesdropping, replaying, and man-in-the-middle (MITM) attacks.